This invention relates to media players for playing media which is received dynamically in a stream of packets. More particularly, it relates to a system and method for varying the play rate of a streaming media player in order to compensate for delays in receipt of packets.
The Internet and various intranets are well known communication networks for the transfer of digital data. While most of the data transmitted on these networks correspond to text or certain computer programs, more and more of it now pertains to multimedia content such as images, audio and video. Typical Web servers follow the HTTP protocol. When a user requests the content of a URL on a server, the entire content associated with that URL is sent to the user""s client machine. Such content comprises an html or htm document with auxiliary information attached to it, such as images and perhaps some animation software. The server will continue sending this data until either it has completed sending all the data or it receives a message from the client to stop sending any more data. Some servers, so-called xe2x80x9cstreaming serversxe2x80x9d, serve in streaming mode, such that the data is sent at some prescribed average data rate, say K bits every N seconds. A streaming server is serviced by a scheduling algorithm to maintain this average data rate.
Media players for decoding and playing audio and video have been standard features on personal computers for more than a decade. Apple* Computers had their QuickTime* player, while machines running Microsoft""s* Windows* operating system had the Microsoft Media Player* (* indicates trademarks of the respective owners) Early streaming media players typically required that data for the entire content to be played first be resident locally on the computer before the player could start playing. This meant that when media data was coming from some other source on the Web, the player would have to wait until the entire contents were downloaded before starting to play. Recently, media players began to support streaming capabilities. Streaming players buffer some data from outside sources on the Web and then start playing, even though much of the data has not yet arrived. If the data rate of the incoming data is not fast enough, the player would pause when the data in its buffer was depleted, rebuffer with more data, and then continue to play. Buffering is also provided to compensate for jitter in the channel.
Streaming media technology has found other new applications. One such application of streaming media technology is the delivery of audio presentations augmented with images or foils. The images are displayed at appropriate time intervals during the audio playback, as prescribed by the authors of the presentation. Various technologies have been invented to accommodate such presentations. Real Networks* is using a file format called SMIL*, which encapsulates all the relevant information in one file, makes certain that all the data that is required during a particular instant of the presentation is already present at the client at such instant, and then streams this file using a streaming server running at some prescribed data rate.
A streaming server delivers data streams isochronally. Typically streaming servers are used to deliver audio and video data, which data is encoded at fixed data rates. When streaming servers deliver video data, for example, the video playback is guaranteed to have smooth motion and sound, provided that the channel bandwidth is high enough. A streaming server sends the video data at controlled bit rates that match the bit rate of the encoded video.
Today""s streaming players handle channel congestion by first depleting the buffer, and, once the buffer is depleted, stopping the playback while the buffer refills up to some prescribed level. Once the buffer is sufficiently full, the player resumes playing This, of course, causes an annoying interruption to the playback.
What is desirable, therefore, and is an objective of the present invention is a streaming media player which can maintain playback even when incoming packets are delayed.
Another objective of the invention is to provide a streaming media player which can sense a delay in receipt of packets before its buffer is empty.
Yet another objective of the invention is to provide a streaming media player which can provide for dynamic adjustment of its playback rate in response to sensed delay in receipt of packets.
The foregoing and other objectives are realized by the present invention wherein the streaming media player receives incoming packets into a buffer and, when the amount of data reaches a first threshold, the media player begins playing back the data. The player is adapted to detect a delay in receipt of incoming packets when its buffer has less than a second threshold of stored information. Upon detection of such a condition, the streaming media player dynamically varies (i.e., slows) its playback rate without changing the pitch, thereby minimally impacting the audio output. The playback rate can be adjusted downward to a preset minimum. The media player will resume its normal playback rate when the buffer contents again reach the second threshold for stored information. Should the buffer contents fall below a third threshold, the player will stop and rebuffer, as had been done in the past.
The present invention provides an alternative for handling channel congestion with either no interruptions or fewer interruptions. The present invention does not wait for the buffer to empty and then stop playing. Rather, when the contents in the buffer are less than a prescribed amount (i.e, the second threshold), the player adjusts its playback speed and slows down sufficiently so that the incoming data rate is at least as large as the outgoing (for playback) data rate, as long as that slowdown is above some preset limit The player dynamically adjusts its playback rate between its ideal rate and one that is allowable yet slow enough to allow the buffer to stay above a third threshold. If the buffer size falls below the third threshold, then the player stops and the buffer again fills. The player continues only once the buffer level has reached some predetermined level (presumably the second threshold).